home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
Floppyshop 2
/
Floppyshop - 2.zip
/
Floppyshop - 2.iso
/
diskmags
/
0022-3.564
/
dmg-0089
/
515.txt
< prev
next >
Wrap
Text File
|
1997-04-16
|
9KB
|
206 lines
=========================================================================
INFO-ATARI16 Digest Sat, 5 May 90 Volume 90 : Issue 515
Today's Topics:
break
Programming self-help
Supercharger problems
update on getting GNU Emacs to work
What is wrong with Terminator's directory?? (2 msgs)
----------------------------------------------------------------------
Date: 5 May 90 02:33:06 GMT
From: rochester!rit!ultb!jdb9608@rutgers.edu (J.D. Beutel)
Subject: break
Message-ID: <3060@ultb.isc.rit.edu>
Does anybody know how break (i.e., ~C) works on the ST?
Is it something in TOS? (I wouldn't think so since I don't
remember hearing about it, and I know some programs don't break.)
Is it done in each language? For instance, does _main() in
Sozobon C scan stdin for ~C and _exit() if it sees it?
(I wouldn't think so since then everything would have to
worry about it.)
I'm asking because I'm toying with the idea of a vi-type
Korn shell based on RTX. I like gu:lam but I don't like microEmacs,
and I miss multi-tasking and job control. So, thinking about
device drivers, SIGSTOP, and the like, I really should understand ~C.
I suppose I could just have the cli slip in an isr to monitor
whatever tty-type input devices, and grap any ~Z that comes along,
but there'll probably be complications if I don't understand
what else is going on.
Or, does Dave Beckmyer's (sp?) shell have vi-like command line editing,
and job control? I haven't seen it, and from what I heard it's a C shell,
but if it does have those other features I'd hate to re-invent the wheel.
I've seen the RTX docs and have the highest respect for RTX's design
(it reminds me of the kernel my OS Lab team did).
--
--
J. David Beutel 11011011 jdb9608@cs.rit.edu "I am, therefore I am."
Looking for co-op Sept..Feb in NN, OS, VR, or AI.
------------------------------
Date: 5 May 90 16:18:12 GMT
From: uvaarpa!murdoch!astsun.astro.Virginia.EDU!gl8f@mcnc.org (Greg Lindahl)
Subject: Programming self-help
Message-ID: <1990May5.161812.440@murdoch.acc.Virginia.EDU>
In article <1990May4.163735.9794@chinet.chi.il.us> saj@chinet.chi.il.us (Stephen
Jacobs) writes:
>Right off the bat: I'm not volunteering to manage this, and it REQUIRES a
>manager, so the idea may be doomed.
>
>There are a lot of questions of the form "How do I get the ST to do job X
>in language Y". These are well answered with small example programs.
Yes, this would be an excellent way to spread documentation about the
ST. How about one example for each BIOS, XBIOS, and GEMDOS call? A few
complete AES/VDI-based programs? Examples that show how to read the
right mouse button, use the VBI queue, work with GDOS.
Any volunteers?
>What I will offer to do is contribute a few goodies of this type myself.
Ditto.
"Perhaps I'm commenting a bit cynically, but I think I'm qualified to."
- Dan Bernstein
------------------------------
Date: 5 May 90 15:04:01 GMT
From: mcgill-vision!quiche!calvin!depeche@BLOOM-BEACON.MIT.EDU (Sam Alan EZUST)
Subject: Supercharger problems
Message-ID: <3344@calvin.cs.mcgill.ca>
In article <8261@rice-chex.ai.mit.edu> jpexg@rice-chex.ai.mit.edu (John
Purbrick) writes:
> In my original posting about the problems with supercharger:
>>Problems:
>>
>>1] Hercules graphics mode is a little screwy.
>> I try it on my mono monitor and about one inch of the screen's image
>> is cut off at the right of the screen. If anyone else experiences
>> this, send me mail. I am really concerned about this bug.
>
>Obviously what they did was just to map the Hercules screen to the ST. Since
>Herc expects 720x348 pixels, you will lose some at the edge. The fact that
>you have a strip at the bottom which isn't used at all is probably not much
>consolation.
>
>John Purbrick
Yes, I am replying to myself.
Sincere apologies - I didn't realize that there is a facility for changing
the portion of the screen which is in view at the given time.
The / key on the numeric keypad lets you view the left edge, right edge,
or the center of the screen (cutting off both sides partially).
I stand corrected. It was a two little lines in the manual which i
must have missed the first few times around...
--
|S. Alan Ezust | depeche@calvin.cs.mcgill.ca|
|McGill University School of Computer Science | Montreal, Quebec, Canada |
|---------------------------------------------------------------------------|
| "The mind is a terrible thing...." |
------------------------------
Date: 5 May 90 17:26:50 GMT
From: zaphod.mps.ohio-state.edu!mips!daver!ditka!rcb@tut.cis.ohio-state.edu
(Roy Bixler)
Subject: update on getting GNU Emacs to work
Message-ID: <24485@ditka.UUCP>
I was finally able to dump GNU Emacs. I fixed the problem of temacs
reporting "End of file during parsing" reading through the loadup.el file by
commenting out the reference to "load site-load file" and just including the
contents of the site-load file itself. As far as I know, running 'dumpfix'
went OK and I now have a valid dumped emacs.
The question is now: when I run xemacs, it always says that it can't find
the termcap file. There is a file in the distribution which claims there is
a sample termcap entry for the atari included, but I can't find the sample
anywhere. Does anyone have a termcap for atari's vt52 emulation? For now,
I'm going to get all vt52 entries out of the termcap file here, but a
specialized termcap for the atari is probably better.
Thanks to Ed Roeder for his help in getting me this far.
Roy Bixler
------------------------------
Date: 5 May 90 15:02:51 GMT
From: swrinde!zaphod.mps.ohio-state.edu!rpi!uupsi!rodan!jfbruno@ucsd.edu (John
F. Bruno)
Subject: What is wrong with Terminator's directory??
Message-ID: <3204@rodan.acs.syr.edu>
In article <9005041337.AA06734@lonex.radc.af.mil> longj@LONEX.RADC.AF.MIL
(Jeffrey K. Long) writes:
>I have been unable to get a directory listing of terminator's "New" directory
>for some time now. Using FTP I can get a list of all the directories and
>see that the "new" directory has an updated time-stamp on it, but when I
>do CD to new and then try to do an "ls", I always get back an "unreadable"
>message. This only seems to happen in the new dirctory, all the others work
>as they always have. Has anyone else seen this problem?
Access to the /atari/new directory has been changed to write-only for
anonymous ftp users. Probably so programs can be checked out before people
start using them, or maybe to stop people from using that directory for
their own purposes, I don't know.
---jb
------------------------------
Date: 6 May 90 00:59:08 GMT
From: usc!zaphod.mps.ohio-state.edu!math.lsa.umich.edu!hyc@ucsd.edu (Howard
Chu)
Subject: What is wrong with Terminator's directory??
Message-ID: <11915@stag.math.lsa.umich.edu>
In article <3204@rodan.acs.syr.edu> jfbruno@rodan.acs.syr.edu (John F. Bruno)
writes:
>In article <9005041337.AA06734@lonex.radc.af.mil> longj@LONEX.RADC.AF.MIL
(Jeffrey K. Long) writes:
> >I have been unable to get a directory listing of terminator's "New" directory
> >for some time now. Using FTP I can get a list of all the directories and
> >see that the "new" directory has an updated time-stamp on it, but when I
> >do CD to new and then try to do an "ls", I always get back an "unreadable"
> >message. This only seems to happen in the new dirctory, all the others work
> >as they always have. Has anyone else seen this problem?
>Access to the /atari/new directory has been changed to write-only for
>anonymous ftp users. Probably so programs can be checked out before people
>start using them, or maybe to stop people from using that directory for
>their own purposes, I don't know.
This is a simple security precaution. By preventing anonymous users from
seeing the filenames in the directory, we reduce the chance that some malicious
screwball will replace a valid program by a virus-infested one (for example)
by uploading a new file with the identical name. There aren't too many good
solutions to managing an archive that's globally writable.
Hard to imagine someone deliberately sabotaging an archive site, but ya never
know. At any rate, with the new indexing efforts, files shouldn't stay in new
very long anyway.
--
-- Howard Chu @ University of Michigan
... the glass is always greener on the side ...
------------------------------
End of INFO-ATARI16 Digest V90 Issue #515
*****************************************